NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/4932

Text File | 1996-08-06 | 9.5 KB | 248 lines

Path: interramp.com!usenet
From: [e-mail] (Barnett E. Kurtz)
Newsgroups: comp.lang.c++
Subject: Re: Old Fortran dog learning new Visual C++ tricks - some questions
Date: Thu, 01 Feb 1996 18:02:46 GMT
Organization: EntroData, Inc.
Message-ID: <4eqvap$[e-mail]>
References: <4en04g$[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: ip38.philadelphia.pa.interramp.com
X-Newsreader: Forte Free Agent 1.0.82

Charles,

First the standard pointers; comp.os.ms-windows.programmer.win32 and
possibly comp.os.ms-windows.programmer.tools.mfc are better places for
questions of this nature.

charles stoyer <[e-mail]> wrote:

>I have been working with Microsoft Developers Studio with C++
>and Fortran 90 Powerstation for about two weeks or so now. I
>come from a purely FORTRAN/assembly language background but
>have been programming for over 25 years. I've gotten pretty far
>and have bypassed the "Hello world" project and created a nifty
>little dialog box application of my own, soon to be available
>on the web for free. The application takes geomagnetic models
>from the USGS and other world geomagnetic agencies and gives
>the earth's magnetic field at the entered location and date. A
>DOS version is available now at
>http://www.interpex.com/interpex/ and is called GEOMAGIX.

Thank You.  If I download it will it improve my C++ skills? :)

>I may be able to field some questions about getting Fortran to
>call and be called from C++, as I have done both. Will be able
>to be more useful as time goes on, I hope.

I think you mean to say that you will be able to field questions
concerning MS PS Fortran & MS VC++ 4.0 static and run-time linking
protocols? Most definitely in comp.os.ms-windows.programmer.win32 I
trust?!

>It seems that support from compiler/system manufacturers has
>gone to the dogs and either they don't answer or they answer a
>different question than was asked.  So I guess we must turn to
>support groups like this.

Most likely NOT comp.lang.c++. Rather...

comp.os.ms-windows.nt
comp.os.ms-windows.nt.pre-release
comp.os.ms-windows.nt.software.backoffice
comp.os.ms-windows.nt.software.compatibility
comp.os.ms-windows.nt.programer.nt.kernel-mode
comp.os.ms-windows.nt.programmer.tools.mfc
comp.os.ms-windows.nt.programmer.win32

comp.os.ms-dos.programmer
.
.
.
comp.os.etc., etc. please check  your news group list more carefully.
Also, consider searching  the MSDN Level 1.  Virtually every one of
your questions is given comprehensive coverage there. Is that 'gone to
the dogs' support?

>I have some questions which I have so far not been able to
>figure out. I have the MSDV CD ROM's, so answers could point me
>there or to the online documentation, if appropriate.

>1. What is a .PCH file and what is it for? It is huge (4Mb)
>even for small programs and exists in both the Release and
>Debug directories. I can't find any reference to it in the
>documentation. Do I need it and can I turn it off?

... .PCH,  a.k.a., a pre-compiled header file. It will continue to
grow unless you take steps to manage the build process by including
the appropriate pre-processor directives. Please read under topic
'pre-compiled headers'.

...Need? No.
...Turn it off? Yes. But all builds using MFC will take a
significantly  longer time to complete. See 'Lean and Mean'
VC_EXTRALEAN below. Flame... it is the price of progress.

One way of organizing your project to make it smaller and quicker to
build might be...

In your application (or class)  .h
// application class
#ifndef __AFXWIN_H__
    #error include 'stdafx.h' before including this file for PCH
#endif
Class GeoTerm        // etc.
{};
...

In your application (or class) .cpp
#include "stdafx.h"
#include "applcation (or class) .h"     //here
...

In stdafx.h    // use the following

#define VC_EXTRALEAN        // To reduce the size of the *.PCH, etc.
#include <afxwin.h>

etc.

>2. You can't call an item which expects a string or string
>pointer with a Cstring argument. Is there some way to copy to
>or recast as a Cstring to a string or string pointer? UPDATE:
>maybe I was doing something else wrong. Anyway, if you have
>comments on the difference between a string and a Cstring, I'd
>be interested.

Please peruse the on-line help for details. Topic CString::CString. In
general the Win32 SDK run-time 'expects' a pointer to the traditional
null terminated array of char for 'strings'. However many Win 32 SDK
functions have MFC equivalents that do handle CString. The NT Win32
SDK also provides for both multibyte (MBCS) and UNICODE 'strings' in
addition to single byte ASCII but each requires its own set of _str
functions and casts. This whole issue is MS platform specific. UNICODE
is supported only on NT. MBCS is supported by both NT and Win95.
Win/16 supports neither. Please see the docs on TCHAR for all the gory
details. In the meantime you can keep the run-time happy and still use
CString. The following assumes you are using the American Standard
char datatype. On Windows that means a single byte, 8 bits per byte.

void MagneticWindows()
{
CString    WinClass;
LPSTR    lpWinClass;

WinClass = "GeoApp";

// For times when a CString won't do.

lpWinClass = new char[WinClass.GetLength()+1];

if (!(lpWinClass == NULL)) {        //Best to write your own exception
 strcpy(lpWinClass,WinClass);    //handler, standard speech.
}

// Most Win SDK does not know about CString, so use...
 ::MessageBox(0,lpWinClass,lpWinClass,MB_OK);

//Most of the Afx, a.k.a. Application FrameWork Extended, a.k.a. MFC
//does understand CString and provides overloaded functions for same.

AfxMessageBox(WinClass);        // no ref but works fine.
AfxMessageBox(lpWinClass);    // works fine too. Ain't C++
wonderful?

delete [] lpWinClass;        // don't forget.
}


Some tips:

1) Don't use CString unless you must.

2) If you do use CString try to do so from the frame rather than the
heap. CString memory management is virtually (pun intended)
non-existant. It has many strange days.

>3. I loaded WIN32S from the new MSDN disk onto a machine
>running Windows 3.11, but there are a lot of libraries missing
>when I try to run my application., for example MSVCRT40.DLL,
>MFC40.DLL and the Fortran library MSFRT40.DLL. Should I be
>building my applications differently? Or is there another
>library I need to load? How can I let Win 3.1x users use my
>application? I tried linking a C++/Fortran app with no runtime
>(=DLL?) libraries, but I am calling AFXMesageBox and it didn't
>like that. NOTE THAT it seems that if you mix languages, if you
>DLL one you must DLL the other or you can't link.

This is VERY MS specific. First, read the distribution notes. Second,
read the on-line help regarding project build options. Third there are
problems (under specific circumstances) when intermixing the new MFC
dlls with the older 2.0 versions. Also, there are limitations using
MFC with Win32s. If possible avoid it. If not spend more time in
comp.os.ms-windows.win32. Hint: Static Link. I know,  it hurts. You
may run into more 'generic' problems with C++ name mangling. I am not
familar with the latest version of MS Fortran. Maybe someone in
comp.os.ms-windows.programmer.win32 will be able to help.

>4. MS claims that OpenGL is available only on Windows NT. Is
>that true? What about 3.1x?
Yes. for WinNT 3.5 and up.
No. for both WinNT 3.1 and Win/16 3.1
..and just in case you forgot to ask .No, WinNT does not support
DirectX. Neither does Win/16.

>5. It looks like radio buttons are treated in a "dumb" fashion
>by the dialog resource editor and the AppWizard. It seems that
>it is the application's responsibility to see that one button
>is turned on and turn the others off before updating data. Is
>that right?

Yes. MFC is not an application painter or generator. It is a
framework. Project Workbench Wizards only outline the application. You
must still fill in the blanks. Think of it as a Template.  The $%@#$
is in the details. The resource editor simply saves you the pain of
typing all the gory details with your editor plus you get to 'paint'
and 'see' what the widget will look like at runtime. If you want
'live' controls see VB or Delphi, or Envelop, or CA-Realizer, or
PowerBuilder, etc. But sooner or later you will still need to code no
matter which tool you select.

>6. Is there an easy way to add a standard system icon to a
>dialog box? For instance, the information icon or the warning
>icon, which seems to come with noises when used with
>AFXMessageBox and the UINT constant MB_ICONINFORMATION?
Yes. read the help. See the samples. It is _very_ easy. The noises may
be coming from an improper sound set up? See your control panel.

>Any answers anyone can give would be appreciated!

Well, I hope this helps. Charles, you need to spend some more time
hitting the docs. You are not in Kansas anymore. Making the jump from
plain old DOS to Windows is not easy. Trying to jump from FORTRAN to
MSVC 32bit programming at the same time may be too long a stretch. Try
concentrating on just C++.  MSVC allows you to build console apps
quickly and easily. No MFC or GUI required! Just use getchar();
anywhere you want to pause to see the results on stdout (printf, cout,
etc)  and the console will pause, just like magic.

I look forward to seeing your posts on
comp.os.ms-windows.programmer.win32 and
comp.os.ms-windows.programmer.tools.mfc. Until Later...

>--
>"You don't need a weatherman to know which way the wind blows"
>(B. Dylan)

>Charles Stoyer, Interpex Limited, Box 839, Golden CO 80401 USA
>[e-mail], CompuServe: 75142.2356
>www/interpex.com/interpex/



-
[e-mail]
-